Universal merchant platform for payment authentication

ABSTRACT

A method of processing of a transaction between a first and second party is provided. The method includes: receiving payment information at a server operatively connected to a communications network, the payment information identifying a particular payment option used by the second party for the transaction, and the server being equipped to format and route messages over the communications network in different manners to accommodate a plurality of different authentication protocols; determining which of the different authentication protocols is prescribed for the type of payment option identified in the payment information; selecting a particular authentication protocol from the plurality of different authentication protocols supported by the server; obtaining an authentication determination for the transaction, including formatting messages and routing the formatted messages over the communications network in accordance with one or more mandates of the selected authentication protocol.

This application is a continuation of U.S. patent application Ser. No.12/959,809, filed Dec. 3, 2010, which is a continuation-in-part of U.S.patent application Ser. No. 12/720,857, filed Mar. 10, 2010, now U.S.Pat. No. 8,140,429, issued Mar. 20, 2012, which is a continuation ofapplication of U.S. patent application Ser. No. 11/419,829, filed May23, 2006, now U.S. Pat. No. 7,693,783, issued Apr. 6, 2010 which is acontinuation-in-part of U.S. patent application Ser. No. 10/459,849,filed Jun. 12, 2003, now U.S. Pat. No. 7,051,002, issued May 23, 2006,which claims priority from U.S. Provisional Application No. 60/388,094,filed Jun. 12, 2002, all of which are incorporated herein by referencein their entirety.

FIELD

The present inventive subject matter relates to the art ofauthentication. It finds particular application in conjunction withfacilitating the authentication of an individual to conduct a securetransaction with a credit or debit card or other payment instrument orpayment means over a communications network, e.g., the Internet, and itwill be described with particular reference thereto. It is to beappreciated, however, that the present inventive subject matter is alsoamenable to other like applications.

BACKGROUND

Internet commerce, or e-commerce as it is otherwise known, relates tothe buying and selling of products and services between consumers andmerchants over the Internet or other like transactional exchanges ofinformation. The convenience of shopping over the Internet has sparkedconsiderable interest in e-commerce on behalf of both consumers andmerchants. Internet sales, or like transactions, have been typicallycarried out using standard credit cards such as Visa®, MasterCard®,Discover®, American Express®, or the like, or standard debit cards,i.e., check cards or automated teller machine (ATM) cards which directlyaccess funds from an associated deposit account or other bank account.Other payment methods have also been developed for making payments inconnection with e-commerce transactions.

For example, these include PayPal®, Bill Me Later®, Secure eBill,Western Union, and the like.

While widely used for more traditional face-to-face transactions, use ofstandard cards in connection with e-commerce presents certaindifficulties, including difficulties concerning authentication orpositive identification of the cardholder. For example, maintainingconsumer confidence in security has become difficult with increasedreports of fraud. The resulting apprehension is also fueled by consumeruncertainty of the reputation or integrity of a merchant with whom theconsumer is dealing. Questionable security of the consumer's cardinformation or other personal information typically submitted along witha traditional e-commerce transaction (e.g., address, card number, phonenumber, etc.) serves to increase apprehension even more. Additionally,cardholders, merchants and financial institutions are all concernedabout safeguarding against fraudulent or otherwise unauthorizedtransactions. Similarly, other payments methods are concerned withsecurity.

Accordingly, various payment networks have implemented initiatives orprograms aimed at safeguarding against fraud. For example, Visa® andMasterCard® both support authentication initiatives whereby a cardholderis authenticated by the bank or financial institution issuing the card,i.e., the issuing bank. FIG. 1, illustrates one such exemplaryauthentication initiative. As shown in this example, aconsumer/cardholder 10, e.g., employing a suitable web browser or thelike, is making an on-line purchase, e.g., over the Internet, from amerchant 20. As is known in the art, the illustrated back-end paymentprocessing chain includes an optional payment gateway 30, the merchant'sfinancial institution or acquiring bank 32, the credit card network 34and the issuing bank 36.

At a point of checkout, the consumer 10 selects an appropriate paymentmethod based on the initiatives supported by the merchant 20. At thispoint, the consumer fills out the on-line checkout form including apayment option, card number, expiration date, etc. Based on the paymentinformation, the merchant 20, via a plug-in 22 installed on theirserver, passes a verify enrollment request (VEReq) message to adirectory 38 on a server, e.g., suitably operated by the credit cardnetwork 34. The directory 38 includes a database associatingparticipating merchants with their acquiring banks and a databaseassociating card number ranges with locations or addresses, e.g.,universal resource locator (URL) addresses, of issuing banks'authentication servers, e.g., the authentication server 40 for issuingbank 36. The VEReq message is a request to verify the enrollment of thecard in the authentication program, and it contains the card numberprovided by the consumer 10.

Based on the card number range stored within the directory, the VEReqmessage will be sent to the appropriate URL address for the server 40which returns to the merchant 20 via the directory 38 a responsethereto, i.e., a verify enrollment response (VERes). That is to say, theserver 40 will verify the enrollment status of the card and respond witha VERes message to the directory 38 which is then passed back to themerchant's plug-in component 22.

Based on the VERes message (i.e., if positive), the merchant plug-incomponent 22 will redirect the cardholder's browser to the server 40 bypassing it a payer authentication request (PAReq) message generated bythe merchant's plug-in component 22. The consumer 10 then completes anauthentication process directly with the server 40. The authenticationserver 40 authenticates the consumer/cardholder 10 and responds to themerchant 20 with a payer authentication response (PARes) messageincluding a digital signature. The merchant's plug-in component 22validates the digital signature of the PARes and extracts theauthentication status and other specified data that is to be used by themerchant 20 during the payment authorization process carried out via theback-end payment processing chain. For example, the merchant 20 sends anauthorization/sale transaction to their payment gateway 30 along withthe data elements received from the PARes. The payment gateway 30 routesthe data to the acquiring bank 32 based on the acquirer's specification.The acquiring bank 32 then sends the data via the appropriate creditcard network 34 to the issuing bank 36 for settlement.

When using authentication initiatives such as the aforementionedexample, the credit card network often ensures participating merchantsthat fraudulent transactions and other charge backs, as they are knownin the art, will not be the merchants' responsibility provided thespecified protocols have been followed. However, there are considerableburdens placed upon the merchants to participate in the authenticationinitiatives. For example, typical installation of the merchant plug-incan be overly burdensome using up resources, i.e., computing power,memory, data storage capacity, etc., the merchant would otherwise preferto devote to other tasks. Often, the plug-in component can be extremelylarge and/or cumbersome to implement on the merchant's server. Moreover,for a merchant that participates in a plurality of such authenticationprograms for multiple credit card networks, the burden can be that muchmore, i.e., requiring a separate plug-in component for each individualauthentication initiative they wish to support, especially consideringthat each credit card network may have its own particular protocols,data fields that are employed in the respective messages, specific dataformat requirements, etc.

Further, the merchants are responsible for remaining current withinitiative protocols that can change periodically. That is to say, asthe authentication protocols are updated and/or changed by therespective credit card networks, the merchants are likewise responsiblefor updating and/or changing their plug-in components to reflect thoseupdate and/or changes being mandated by the credit card networks.

The present inventive subject matter contemplates a new and improvedsystem and/or method which overcomes the above-referenced problems andothers.

SUMMARY

In accordance with one aspect of the present invention, a method isprovided for supporting processing of a transaction conducted between afirst party and a second party. The first party accepts payment via aplurality of different payment options selectable by the second party,and the plurality of different payment options are associated with aplurality of different authentication protocols prescribed therefor. Themethod includes: receiving payment information over a communicationsnetwork at a server operatively connected to the communications network,the payment information identifying a particular payment option used bythe second party for the transaction, and the server being equipped toformat and route messages over the communications network in differentmanners to accommodate the plurality of different authenticationprotocols; determining from the payment information received at theserver which of the different authentication protocols is prescribed forthe type of payment option identified in the payment information;selecting, in accordance with the determination, a particularauthentication protocol from the plurality of different authenticationprotocols supported by the server; and, obtaining an authenticationdetermination for the transaction in accordance with the selectedauthentication protocol, including formatting messages and routing theformatted messages over the communications network in accordance withone or more mandates of the selected authentication protocol.Optionally, a one-time card number may be generated to be sent back tothe first party.

In accordance with another aspect of the present invention, a system isprovided for supporting processing of a transaction conducted between afirst party and a second party. The first party accepts payment via aplurality of different payment options selectable by the second party,and the plurality of different payment options are associated with aplurality of different authentication protocols prescribed therefor. Thesystem includes: at least one server that is operable to receive paymentinformation over a communications network at a server operativelyconnected to the communications network, the payment informationidentifying a particular payment option used by the second party for thetransaction, and the server being equipped to format and route messagesover the communications network in different manners to accommodate theplurality of different authentication protocols; determine from thepayment information received at the server which of the differentauthentication protocols is prescribed for the type of payment optionidentified in the payment information; select, in accordance with thedetermination made by the means for determining, a particularauthentication protocol from the plurality of different authenticationprotocols supported by the server; obtain an authenticationdetermination for the transaction in accordance with the selectedauthentication protocol, including means for formatting messages androuting the formatted messages over the communications network inaccordance with one or more mandates of the selected authenticationprotocol; and generate a one-time card number to be sent back to thefirst party.

Numerous advantages and benefits of the present inventive subject matterwill become apparent to those of ordinary skill in the art upon readingand understanding the present specification.

BRIEF DESCRIPTION OF THE DRAWINGS

The present inventive subject matter may take form in various componentsand arrangements of components, and/or in various steps and arrangementsof steps. The drawings are only for purposes of illustrating preferredembodiments and are not to be construed as limiting.

FIG. 1 is a block diagram illustrating a typical e-commerce transactioncarried out in accordance with an exemplary authenticationinitiative/program of a credit card network.

FIG. 2 is a diagrammatic illustration showing a high level overview ofan exemplary processing of an authenticated commercial transaction inaccordance with aspects of the present inventive subject matter.

FIG. 3 is a block diagram illustrating an exemplary merchant server andexemplary merchant authentication processing system in accordance withaspects of the present inventive subject matter.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

For clarity and simplicity, the present specification shall refer tostructural and/or functional network elements, entities and/orfacilities, relevant standards, protocols and/or services, and othercomponents that are commonly known in the art without further detailedexplanation as to their configuration or operation except to the extentthe same has been modified or altered in accordance with and/or toaccommodate aspects of the present inventive subject matter.

In accordance with a preferred embodiment, the present inventive subjectmatter serves as a centralized merchant processing system forauthenticated payments, allowing a merchant or their proxy to securelyand easily accommodate authentication of consumers and/or cardholders inaccordance with a variety of authentication initiatives implemented bycredit card networks or other payment networks, and to processelectronic transactions through any payment network using a singleplatform. It also enables merchants or their proxies to process thesepayments, regardless of which payment network they are to be routedthrough, with a single implementation. In one version, this isaccomplished using “thin-client” communication software which linksinformation with a centralized merchant authentication processing system(MAPS) upon demand. Moreover, it allows them or a funding source to usethe established underlying payment processing infrastructure to processtheir credit/debit or other payment instruments at participatingmerchant sites.

The advantages to funding sources are: the ability to authenticate usersand process all electronic transactions through a single platform; theability to seamlessly process payments using any given payment network;a reduction in processing costs; increased use of their credit/debit orother payment instrument; increased acceptance of their credit/debit orother payment instrument; the ability to send authenticated payment andauthorization requests to any network; the ability to receive detailedconsumer purchasing behavior statistics. Likewise, there are advantagesto the merchant, including, but not limited to: the ability to complywith, participate in, and enjoy the benefits of a variety of differentauthentication initiatives; the ability to authenticate consumers usingdifferent payment vehicles or credit cards, thereby avoiding lost sales;and, protection from fraud.

The approach detailed in the present specification provides a secure,scalable and modular solution for merchants to participate in andsupport various payment authentication initiatives, such as, e.g.,Visa's 3-D Secure Verified by Visa (VbV) and MasterCard's SecureCodeand/or Secure Payment Application (SPA). It provides payment gateways,acquirers, merchant service providers (MSP) and independent salesorganizations (ISO) an easy and effective way to provide their merchantswith the means for cardholder or account holder authentication, asdefined by various authenticating programs, e.g., VbV, SecureCode, SPA,etc.

With reference to FIG. 2, a high level overview of an exemplarycommercial transaction carried out in accordance with aspect of thepresent inventive subject matter is diagrammatically illustrated. Via acomputer, a consumer 50 shops at an on-line merchant 60 using a selectedpayment instrument. When the transaction is completed, transactiondetails are sent from the merchant 60 to a transaction processingservice provider (TPSP) 70 that formats and routes various messages andtakes other defined actions on behalf of the merchant 60 in accordancewith authentication protocols prescribed by the payment processingnetwork to which the payment instrument being used for the transactionbelongs. For example, as shown, there is an ATM card payment processingnetwork 70, a first credit card payment processing network 72 for afirst type or brand of credit card, a second credit card paymentprocessing network 74 for a second type or brand of credit card, a checkcard payment processing network 76, and a private label credit cardprocessing network 78, all of which optionally support differentauthentication protocols. Of course, optionally, other types of paymentprocessing networks may also be included. As shown, the TPSP 70optionally obtains transactions from the merchant and distributes themto the proper payment processing networks, e.g., for directauthentication by the entity issuing the payment instrument used in thetransaction. Having obtain an authentication determination, theauthentication service provider 70 then returns this determination tothe merchant 60 so that it may be included when the transaction issubmitted by the merchant 60 to the established underlying paymentprocessing infrastructure, e.g., via an optional payment gateway 80.

More specifically, with reference to FIG. 3, an exemplary server 100operated by an on-line merchant and an exemplary merchant authenticationprocessing system (MAPS) 200 are shown. The merchant server 100 includesa checkout processing function 102, a payment processing function 104and a thin-client 106 operative to provide interworking between theserver 100 and the MAPS 200. The server 100 suitably hosts a websiteaccessible over a communications network (e.g., the Internet) byconsumers/cardholders to conduct commercial transactions, i.e., topurchase good and/or services. That is to say, a consumer/cardholderusing an appropriate web browser or like application may connect to theserver 100 over the Internet to shop on the hosted website.

Suitably, when a consumer/cardholder is done shopping, the checkoutprocessing function 102 is invoked thereby providing the consumer's webbrowser with a checkout webpage whereby the transaction amount (i.e.,the total amount of payment due) is established and/or presented andpayment information collected. The checkout processing function 102supports payment with a plurality of different types of paymentinstruments, e.g., credit and/or debit cards, belonging to differentpayment processing networks, e.g., Visa®, MasterCard®, etc. Alternately,other payment options may include PayPal®, Bill Me Later®, WesternUnion, Secure eBill, etc. That is to say, the consumer/cardholderoptionally selects the particular type of payment instrument or paymentmethod being used for the commercial transaction from a plurality ofsupported payment types. Additionally, the checkout processing function102 is also used to collect the card number, expiration date, and otherrelevant payment data from the consumer/cardholder.

The payment processing function 104 submits completed transactions tothe established underlying payment processing infrastructure (i.e.,payment gateway, acquiring bank, payment processing network, issuingbank, etc.) in the usual manner as prescribed by the various paymentprocessing networks.

The merchant's thin-client 106 is used for communicating transactiondata elements such as card number, account number or name, transactionamount, etc. between the merchant's website and the MAPS 200. Thethin-client is not aware of the specific processing logic or protocolsprescribed for each payment authentication initiative. Suitably, thethin-client 106 is a small software component installed on themerchant's server 100, e.g., approximately 50 kilobytes in size.Alternately, the following options for connecting to the MAPS 200 arealso available in order to cater to different merchants depending uponthe merchant's transaction processing volume, technical expertise,resource availability and software standards: (i) an “easy connection”implementation, as it is termed herein, i.e., a software-less merchantclient; and (ii) a “direct connection” implementation, as it is termedherein, i.e., a direct integration within the MAPS 200. Nevertheless,the thin-client approach provides the merchant with a thin (i.e., small)software object (e.g., approximately 50 kilobytes) that is used by themerchant to communicate with the MAPS 200. Using the thin-client 106,the merchant can participate within the various payment authenticationinitiatives, e.g., VbV, SPA, etc., without any significant reprogrammingof the server 100 or their website. Suitably, the thin-client 106 isavailable as a COM object or a Java component that is integrated withthe merchant's established transaction handling process.

The thin-client software is used by the merchants to securelycommunicate with the MAPS. The thin-client software is used to formatname/value pairs to the designated MAPS message format and securelycommunicate the message to the MAPS system. Suitably, the thin-clientdoes not hold any payment authentication specific business processlogic. The thin-client supports the following features: securecommunication to the MAPS 200, formatting data to the MAPS specificmessage format, and allowing merchants to access response data.

Suitably, the architecture of the thin-client 106 includes a requestlayer 110 and a response layer 112 that sit on top of a messageformatting layer 114 that sits on top of a communication layer 116. Therequest layer 110 provides an interface that can be accessed by themerchant's web site to provide data to the thin-client 106 in the formof name/value pairs. The request layer 110 also exposes functions forthe merchant to send messages to a specific MAPS 200. The response layer112 provides an interface for returning responses to the website, e.g.,returned as a function call response to a send message instruction. Themessage formatting layer 114 formats and translates traffic between therequest and response layers 110 and 112 which employ a name/value pairsformat and the communication layer 116 which suitably employs an XMLformat to communicate with the MAPS 200. Of course optionally, otherformats may also be used to communicate with the MAPS 200, e.g., SimpleObject Access Protocol (SOAP), Short Message Service (SMS), a CommaSeparated Value (CSV) or other like format (using flat files or batchfiles), etc. The communication layer 116 provides connectivity with theMAPS 200, e.g., via HTTPS (i.e., hypertext transfer protocol over securesocket layer (SSL)).

The MAPS 200 is a core component within the system. The MAPS 200provides the functionality to merchants for participation in the variousdifferent authentication programs and initiatives supported by thepayment processing networks. Suitable, the MAPS 200 architecture isextensible to support existing and new releases of existing paymentinitiatives without requiring a total software rewrite, and likewiseaccommodates addition of new authentication initiatives. This approachleads to an easy implementation at the merchant website level, i.e.,where the processing logic and message handling prescribed by theinitiatives are controlled at a central location rather than at anindividual merchant level. That is to say, any changes or additionsimplemented do not affect individual merchants.

The MAPS 200 provides a secure infrastructure for processingtransactions based on payment authentication initiative specifications.The MAPS 200 provides extensible software than can seamlessly supportfuture revisions of the existing payment authentication initiatives andnew payment authentication initiatives. Preferably, the MAPS 200provides complete abstraction as to how each payment authenticationinitiative is implemented, thereby providing one central location forany changes. Suitably, the MAPS 200 is programmed with Java software toprovide the described functionality. The MAPS software architectureincludes the following layers: a connectivity layer 210 that sit on topof a message distribution layer 220 that sit on top of a plug-in layer230, and external connection layer 240. The external connection layer240 provides a generic interface that is used by the MAPS 200 tocommunicate with outside resources, e.g., the directory or the like asprescribed by various authentication protocols.

The connectivity layer 210 provides a generic layer for externalentities such as merchants to connect to and process a specific paymentauthentication transaction. The connectivity layer 210 supports thefollowing connectors: an HTTPS server 212; a “direct connector” 214, asit is termed herein; and, an “easy connector” 216, as it is termedherein; and an optional “other connector” 218, as it is termed herein.

The HTTPS server 212 receives and/or sends HTTP messages andcommunicates them to and/or from the message distribution layer 220.This connector is used by the thin-client 106 to communicate with theMAPS 200. The direct connector 214 provides a Java interface than can beused by a merchant integrating with the MAPS 200 using the directconnection approach. This connector exposes the appropriate Javainterfaces than can be used by the merchant during integration. Messagesreceived/sent using this connector are also communicated to/from themessage distribution layer 220. The easy connector 216 provides a webserver that is used to communicate with the message distributor and alsoto communicate with the cardholder. This connector interfaces with thecardholder to perform the merchant functionality and interfaces with themessage distributor to communicate the relevant messages. Suitably, theother connector 218 allows the connectivity layer 210 to be expanded tosupport other communication and custom integration options.

Implementing multiple connector types provides multiple ways formerchants to integrate and participate within the various authenticationinitiatives. By providing multiple integration approaches, a widevariety of merchants can be supported depending upon the merchant'stechnical expertise, resource availability and transaction processingvolume. That is to say, in addition to the thin-client approach, a“direct connection” and “easy connection” approach are also optionallyavailable to merchants.

The direct connection approach is provided for merchants which insist onor otherwise want to host and manage the product, e.g., such merchantsmay be high transaction volume merchants and/or merchants who have thetechnical resources to host and manage the product. The merchant can usedirect Java calls or the like to interface with the MAPS 200 andcommunicate the appropriate XML or other like messages. The directconnect interface is also available via a local socket server providedas part of the MAPS 200. Merchants utilizing a software platform otherthan Java can use the local socket server. Under the direct connectionapproach the merchants provide their own hardware and/or software. Onthe opposite end of the spectrum, the easy connection approach isprovided as a software-less integration approach for merchants that donot wish to install the thin-client 106. Using the easy connectapproach, the merchant redirects the cardholder to the MAPS easy connectweb server. The web server acts on behalf of the merchant's website andcommunicates with the MAPS 200 to provide the appropriate processing forthe appropriate authentication initiative. Under this approach, themerchant redirects the cardholder using HTTPS posts and receives theresponses at a specified response URL. HTTP redirections are performedvia the cardholder's browser. Using the easy connection approach themerchant may place an appropriate script after the cardholder/consumerhas provided the merchant with appropriate payment data, such as creditcard number, expiration date, etc. The merchant receives theauthentication response at the URL specified within a response URL fielddesignated in the script.

The message distribution layer 220 is a component within the softwarearchitecture that facilitates scalability, redundancy, high availabilityand transaction processing speed. Suitably, the message distributionlayer 220 is developed using Java 2 Enterprise Edition (J2EE)specifications related to transaction processing. It is preferably a lowfootprint message distribution application configured to route XML orother like messages to specific plug-in components in the plug-in layer230 for appropriate transaction processing.

The plug-in layer 230 includes a plurality of individual authenticationinitiative plug-in components 232 that listen to the messagedistribution layer 220 for a specific message type. The respectiveplug-in component 232 is activated by the message distribution layer 220that sends messages to the specified plug-in component 232 based uponthe type of payment instrument or method being used for the transactionbeing processed. For example, as shown, the MAPS 200 optionally includesplug-in components 232 for Visa®, MasterCard® and other paymentinstruments or methods. Notably, the plug-in components 232 are freelyand easily updated, exchanged or otherwise manipulated as desired tocomply with new version of existing authentication initiatives, oradditional plug-in components are freely and easily added to accommodatenew initiatives, without any additional alterations to the MAPS 200 oron the merchant side. In this manner, the merchants are automaticallykept in compliance with the latest authentication initiatives withouthaving to rework authentication processing protocols on their server100. Further, as other payment processing enhancements are introducedand/or desired, e.g., currency conversion, compliant plug-in componentstherefor may likewise be developed and simply added to the plug-in layer230 of the MAPS 200 thereby providing the merchant with the particularpayment processing functionality.

Additionally, the plug-in layer 230 optionally also supports variousmanagement and/or administrative applications (not shown). For example,a merchant registration application module may be made available tomerchant service providers (MSPs) for registering their merchants withinthe appropriate payment authentication initiatives. Suitably, themerchant registration application offers a web-based application, wherethe merchants, based on communications received from their MSPs, canregister themselves and download appropriate software and relatedintegration documentation. The merchant registration application alsoprovides registration/license key-based control to the MSP, where theMSP can communicate a license key to the merchant that will be used toauthenticate the merchant during registration and download. Optionally,the data elements collected from the merchants can be customized asdesired by the MSP.

An optional MSP administration application provides the MSP with aweb-based application that is used to administer merchants. The MSPadministration application may, e.g., provides the following features:enabling/disabling merchants for use of the MAPS 200; maintainingmerchant profile information; etc. The MSP administration application isoptionally accessed directly via XML/HTTP based application programinterfaces (APIs) that may also be used to integrate with other systems.Additionally, a merchant self-service application allows the merchant toaccess their profile information via the web. For example, the merchantself-service application optionally offers the following features: selfprofile management; access to transaction history; access to raw messagelogs related to authentication processes; etc. The merchant self-serviceapplication may be similarly accessed directly via XML/HTTP based APIsthat are optionally also used to integrate with other systems.

As another option, a MSP reporting application provides a web-basedapplication for MSPs to view consolidated and individual transactionlistings. For example, the following reports may optionally be providedas part of the MSP reporting application: consolidated transactioncount/dollar volume reports; individual transaction reports; raw messagelogs; merchant registration reports; and/or other customized reports.

As will be appreciated by those of ordinary skill in the art, the MAPS200 provides a method for authenticating a consumer using one of aplurality of different types of payment instruments (e.g., credit/debitcards) or payment methods to conduct a commercial transaction over acommunications network with a merchant employing the MAPS 200. Thepayment instrument or method may be either enrolled in or not enrolledin an authentication program conforming to one of a plurality ofauthentication protocols prescribed for the respective plurality ofdifferent types of payment instruments by payment networks supportingthe same.

Suitably, via the thin-client approach (or alternately the direct oreasy connection approaches) the MAPS 200 obtains payment information forthe transaction from the merchant's server 100. Suitably, the paymentinformation includes a number or name identifying the particular paymentinstrument or account being used (i.e., the card number or accountnumber or account name), an expiration date, transaction details (i.e.,the transaction amount, etc), and other pertinent payment data. In thecase of the thin-client approach, the payment information is obtainedfrom the merchant's website or page via the request layer 110 in theform of name/value pairs. The request layer 110 passes the paymentinformation to the message formatting layer 114 that translates it intoan XML or otherwise appropriately formatted message and passes it to thecommunication layer 116. The communication layer 116 then passes themessage in the XML format or other suitable format to the MAPS 200 viathe HTTPS server 212 in the connectivity layer 210.

Upon receiving the payment information, the MAPS 200 determines the typeof payment instrument or method being used from the payment information.Notably, the payment processing network to which a credit/debit cardbelongs can be determined from the card number as is known in the art.

Optionally, the MAPS 200 determines from the enrollment status of theparticular payment instrument or account being used for the transaction.For example, the MAPS 200 may maintain a local cache or database of cardnumbers that identifies those payment instruments enrolled forparticipation in various authentication programs and/or initiatives. Ifthe particular payment instrument being used is not enrolled in aparticular authentication program for the determined type of paymentinstrument or method, then the process may be ended at this point withthe MAPS 200 retuning a “not enrolled” message or data back to thethin-client 106 installed on the merchant's server 100. Accordingly, thethin-client 106 passes this information to the payment processingfunction 104 to be bundled with the transaction data for submission ofthe completed transaction to the established underlying paymentprocessing infrastructure. It is to be appreciated, that the returned“not enrolled” message or data, as with all such information returned tothe merchant, is provided by the MAPS 200 through the thin-client 106(i.e., through the communication layer 116, the message formatting layer114 and the response layer 112) such that it emerges already formattedand/or otherwise in compliance with the appropriate authenticationprotocols prescribed so that the merchant does not have to manipulatethe data further prior to submission to the established underlyingpayment processing infrastructure.

Alternately, if the particular payment instrument being used is enrolledin an authentication program, then the payment information is passed tothe message distribution layer 220 that routes it to the proper plug-incomponent 232 in the plug-in layer 230. The plug-in component 232 thenhandles, administers and/or otherwise executes set procedures prescribedfor the respective authentication program employing the appropriateprotocols and/or logic to obtain an authentication determination for thetransaction. For example, the plug-in component 232 formats and routesmessages in accordance with the authentication protocols prescribed forthe determined type of payment instrument or method being used. Havingobtained the authentication determination, the MAPS 200 returns the sameto the merchant's server 100.

Suitably, the plug-in components 232 are programmed to administer any ofa variety of authentication protocols as may be prescribed for differenttypes of payment instruments or methods support be various paymentprocessing networks. For example, to accommodate a particularauthentication initiative, a particular plug-in component 232 optionallyformats and routes a messages to an issuing entity, e.g., an issuingbank having issued the particular payment instrument being used for thetransaction, requesting that the issuing entity confirm the enrollmentstatus of the particular payment instrument being used for thetransaction. Upon obtaining a response to the enrollment request messagefrom the issuing entity, the information may be returned to themerchant's server 100 in the same manner as if the MAPS 200 performedthe enrollment check itself.

Additionally, once the enrollment status is determined to be positive,the operative plug-in component 232 optionally formats and routes asecond message to the merchant such that the consumer/cardholder isredirected to the issuing entity for completing authentication directlytherewith, whereupon the authentication determination is made. Aresponse containing the authentication determination made by the issuingentity is then returned in accordance with routing instructionscontained in the second message so that it is obtained by the MAPS 200.Suitably, the routing instructions include a universal resource locator(URL) directing the response back to the MAPS 200. Optionally, theplug-in component 232 verifies that the response to the second messagewas obtained from the issuing entity, e.g., by checking a digitalsignature incorporated with the response. The MAPS 200 is alsooptionally equipped to detect and/or qualitatively evaluate the leveland/or type of authentication employed to arrive at the authenticationdetermination, and this information may be communicated to the merchantor others.

To further comply with another selected authentication initiative, aparticular plug-in component 232 is optionally programmed such that theMAPS 200 is equipped to dynamically add one or more data fields to themerchant's webpage so as to bring the merchant's webpage into conformitywith prescribed authentication protocols for the determined type ofpayment instrument. Additionally, other data elements and/or fields mayoptionally be dynamically added, e.g., to provide currency conversion,etc.

Suitably, the MAPS 200 further includes a database (not shown) in whichhistorical records of transactions processed by the MAPS 200 aremaintained. The historical records can then be optionally accessed bythe merchants or MSPs to perform audit trail and/or reconciliationoperations.

It is to be appreciated that the foregoing description and theaccompanying figures are merely exemplary in nature. In particular,other hardware and/or software configurations recognizable to one ofordinary skill in the art may be employed to implement the presentinvention, and other similar payment authentication initiatives, i.e.,other than the exemplary VbV and SPA, may likewise be supported withoutdeparting from the scope of the present invention. Nevertheless, thearchitecture described in the present specification achieves certainbenefits. For example, the availability of multiple implementationapproaches (i.e., thin-client, direction connection and easy connection)allows a customized fit to a variety of differently equipped merchantsbased upon their transaction processing volume, technical expertise,software and/or hardware resources, etc. Further, the centralized MAPS200 removes the burden otherwise placed on the merchant's server 100having to support multiple payment processing initiatives providingsubstantially complete abstraction related to individual paymentauthentication initiative processing rules and logic, and with itsextensible plug-in layer 230, provides availability to multiple paymentauthentication initiatives with one implementation on the merchant side.

Additionally, where the merchant employs a MSP to perform paymentprocessing and/or related tasks on the merchant's behalf, it is to beappreciated that the MSP may effectively step into the position of themerchant relative to the MAPS 200. For example, rather than thethin-client 106 being installed on the individual merchant's server 100,it may be installed on the MSP's server which may use it on behalf of asingle merchant or multiple merchants serviced by the MSP. That is tosay, information and/or data to and/or from respective merchants wouldfirst be routed through the MSP's server where it is exposed to and/orinteracts with the thin-client 106 installed thereon in essentially thesame manner as described above. Of course, any other suitable proxy maysimilarly take the position of the merchant. Moreover, rather thanreturning authentication determinations and/or other transactionprocessing results back to the merchant, it is to be appreciated thatoptionally the information or results may be sent or directly forwardedfrom the MAPS 200 to any other selected or designated entity within thechain completing back-end processing of the completed transaction, e.g.,a merchant's payment gateway, acquiring bank, payment or credit cardnetwork, issuing bank, etc.

As stated earlier, additional plug-in components 232 may be added to theplug-in layer 230 of the MAPS 200 to provide the merchant with aparticular payment processing functionality. In this regard, oneadditional plug-in component may comprise, for example, a credit/debitcard number generator that, among other things, is operable to create anon-repeating, non-guessable credit/debit card number (wherenon-repeating may be limited to one year, for example) for a giventransaction. An exemplary credit/debit card number generator may operatein the manner described below.

In computing and electronic systems, binary-coded decimal (BCD)(sometimes called natural binary-coded decimal, NBCD) or, in its mostcommon modern implementation, packed decimal, is an encoding for decimalnumbers in which each digit is represented by its own binary sequence.Its main value is that it allows easy conversion to decimal digits forprinting or display, and it allows faster decimal calculations. In BCD,a digit is usually represented by four bits, which, in general,represent the decimal digits 0 through 9. Other bit combinations aresometimes used for a sign or for other indications (e.g., error oroverflow).

A “Machine Id” is thus created by the least significant byte of the IPaddress. Thus, for example, the binary-coded decimal (BCD) of the mostsignificant digit of the “Machine ID” may be {0,1,2}. “Time This Year”refers to the number of seconds in this year. The BCD of the mostsignificant digit of the “Time This Year” may be {0,1}, for example.These digits may be encoded as set forth in Table 1 below:

TABLE 1 Time This Year Machine ID Encoding 0 0 0 0 1 1 0 2 2 1 0 3 1 1 41 2 5

A remapping function (“Remap Digits”) may have as its inputs: “MapSignificant Digit,” “Time This Year,” and “Random.” “Random” refers to aFederal Information Processing Standards (FIPS) secure random numberthat is generated to add a random component to the pan.

In particular, the remapping function “Remap Digits” uniquely maps everyvalue to a unique value to make a “hard to guess” value. The remappingfunction may be explained through the following example. Imagine time asa deck of cards in order, where Position 1=Ace of Spades, Position 2=2of Spades, and so on. Now, if the deck is shuffled (randomized), everyposition will likely have a new card. But, obviously, no two positionswould have the same card. That is, a scenario where Position 5=6 ofClubs and Position 16=6 of Clubs is not possible in the same deck.

Likewise the variables “Map Significant Digit” and “Time This Year” arelike the cards and are “shuffled” (randomized) with this samemethodology. However, there are preset “shuffles” that correspond to the“Random” digits.

Consider a simplified example. That is, if the random digits are 123456and the time is 123456, the shuffle might always be 246321. Note thatthere are no repeating digits. Further, time 123457 and the same randomdigits 123456 would be 247321.

In actuality, the remapping function does more than just “reorder” thedigits. That is, it guarantees that for a “Random” digit a unique remapvalue is generated:

<Card Number Generator>-<bin><Remap Digits><Random><Mod10>

In this regard, it is noted that the “modulus 10” or “mod 10” algorithm,also known as the Luhn algorithm or Luhn formula, is a simple checksumformula used to validate a variety of identification numbers, such ascredit card numbers. Further, uniqueness is generally only guaranteedwithin the overall time period (e.g., one year) and the desiredresolution (e.g., 1 sec). As a Machine ID is used, a history of all panswithin the resolution (e.g., 1 sec.) is kept in memory in order toguarantee that a unique number is generated. One year is typicallyconsidered sufficient for the validity of the generated number, but thetime period could be longer or shorter.

Thus, with this additional plug-in component, a one-time numbercorresponding to a credit/debit card may be generated and sent back to aparty involved with the transaction. By way of example, an exemplarymethod of supporting the processing of a transaction conducted between afirst party and a second party is set forth below.

In this example, the first party generally accepts payment via anynumber of different payment options selectable by the second party, anda variety of different payment options are associated with a number ofdifferent authentication protocols prescribed therefor. The methodincludes receiving payment information over a communications network ata server operatively connected to the communications network, thepayment information identifying a particular payment option used by thesecond party for the transaction, and the server being equipped toformat and route messages over the communications network in differentmanners to accommodate the different authentication protocols. Next, adetermination is made as to which of the different authenticationprotocols is prescribed for the type of payment option identified in thepayment information based on the payment information received at theserver. In accordance with the determination made, a particularauthentication protocol from the different authentication protocolssupported by the server is selected. An authentication determination isobtained for the transaction in accordance with the selectedauthentication protocol, including formatting messages and routing theformatted messages over the communications network in accordance withone or more mandates of the selected authentication protocol. Finally, aone-time credit/debit card number to be sent back to the first party isgenerated.

It is to be appreciated that optionally the one-time number may be sentor directly forwarded from the MAPS 200 to any other selected ordesignated entity within the chain completing back-end processing of thecompleted transaction, e.g., a merchant's payment gateway, acquiringbank, payment or credit card network, issuing bank, etc.

It is to be understood that the additional plug-in components mayincorporate various aspects and features, such as an Order Id, aReporting service, a Settlement service, Pay Enable, a ProcessingModule, a Widget and a Virtual Terminal, which are defined below.

The term “Order Id” refers to a “mod 10” compliant number in anon-routeable bin range referring to a merchant specific transaction

The term “Reporting” refers to a service provided to a legacy system toprovide Alternative Payment specific details. Alternative Paymentmethods may include, for example, PayPal®, Bill Me Later®, Secure eBill,Western Union, and the like. The legacy system need not understand theAlternative Payment schema. By way of example, a legacy system would usethe Order Id internally and keep track of accepted/declined states justas a credit card. If additional detail is required, such as a PayPal®transaction id, a request could be made into Reporting, which wouldreturn Alternative Payment specific details. The legacy system wouldsimply render the details without interpretation.

The term “Settlement” refers to a service provided to legacy systems tosettle Alternative Payments just as credit cards. By way of example, theMAPS 200 may return the Order Id during the checkout phase for anAlternative Payment, such as PayPal®. The legacy system just needs tostore the Order Id in the credit card field. When the settlement of thetransaction occurs, all credit cards in the Order Id bin range can beprocessed through the Settlement service. Familiar accept/decline resultcodes are returned. Payment type specific details are available viaReporting.

The term “Pay Enable” refers to a service to convert batch files invarious formats into real-time transactions. By way of example, thisfeature may involve processing Paymentech batch files and splitting offPayPal® transactions and re-generating a credit card only Paymentechbatch file.

A “Processing Module” may provide the ability to facilitateauthorizations (V, MC, AmEx, Discover), handle exceptions (chargebacks,credits, manual adjustments), and complete performance monitoring(latency, time-outs, volume).

The term “Order Pusher” refers to a service that pushes an authorized orcaptured order into a merchant's shopping cart and/or order managementsystem (OMS). For example, a consumer may be redirected to Google forpayment. The MAPS 200 can push the order into the merchant's OMS withthe Order Id once Google has authorized funds.

The term “Widget” refers to a Web “code” that uses, for example, ajaxtechnology (shorthand for Asynchronous JavaScript and XML) to present asimple link on the merchant's shopping cart to facilitate AlternativePayments such as PayPal Buy Now.

The term “Virtual Terminal” refers to a terminal (or kiosk) to manuallyrun transactions. These transactions may include, for example, MOTO(Mail Order and Telephone Order) transactions. With MOTO transactionsthe merchant does not receive a signature from the customer, but onlythe credit card number and expiration date.

The invention has been described with reference to the preferredembodiments. Obviously, modifications and alterations will occur toothers upon a reading and understanding of this specification. It isintended that the invention be construed as including all suchmodifications and alterations insofar as they come within the scope ofthe appended claims or the equivalents thereof.

1. A method of supporting account holder authentication in connectionwith a transaction conducted between a first party and a second party,wherein the first party accepts payment via a plurality of differentpayment options selectable by the second party, said plurality ofdifferent payment options being associated with a plurality of differentauthentication initiatives prescribed therefor, said method comprising:receiving payment information over the Internet at a server operativelyconnected to the Internet, wherein a particular payment option used bythe second party for the transaction is determinable from said paymentinformation, and said server is equipped to at least one of format androute messages over the Internet in different manners to accommodate theplurality of different authentication initiatives; determining from thepayment information received at the server which of the differentauthentication initiatives is prescribed for the type of payment optionidentified in the payment information; selecting, in accordance with thedetermination made, a particular authentication initiative from theplurality of different authentication initiatives supported by theserver; and, obtaining an authentication determination for thetransaction, said authentication determination being produced inaccordance with the selected authentication initiative.
 2. The method ofclaim 1, wherein the payment information is received from a server ofthe first party.
 3. The system of claim 1, wherein the authenticationdetermination is obtained from a server of a third party, said thirdparty maintaining an account for the second party, said accountcorresponding to the payment option used by the second party for thetransaction.
 4. The method of claim 1, wherein at least one of theplurality of authentication methods differs from at least another of theplurality of authentication methods by the way in which theauthentication determination is formatted.
 5. A method that supportsauthentication of a purchaser as an account holder in connection with atransaction conducted between the purchaser and a merchant, wherein themerchant accepts payment via a plurality of types of payment instrumentsselectable by the purchaser, each type of payment instrument beingassociated with an authentication initiative, each authenticationinitiative prescribing a manner in which an account holder is to beauthenticated, said method comprising: communicating with a first serverof the merchant to receive therefrom payment information over theInternet at a second server; determining from said received paymentinformation the type of payment instrument used for the transaction,said determining executed by the second server; and obtaining anauthentication determination at the second server, said authenticationdetermination being produced in accordance with the authenticationinitiative associated with the determined type of payment instrument. 6.The method of claim 5, wherein the plurality of types of paymentinstruments includes at least a Visa type of payment instrument and aMasterCard type of payment instrument, said Visa type of paymentinstrument being associated with a first authentication initiative andsaid MasterCard type of payment instrument being associated with asecond authentication initiative.
 7. The method of claim 6, wherein thefirst authentication initiative is different from the secondauthentication initiative in at least one of a way authenticationdeterminations are formatted, a location to which at least one messageis routed in order to obtain an authentication determination and a wayin which at least one message is formatted in order to obtain anauthentication determination.
 8. The method of claim 5, wherein saidpayment information includes a number of the payment instrument used forthe transaction, and the type of payment instrument use for thetransaction is determined from said number.
 9. The method of claim 5,wherein obtaining the authentication determination comprises: at leastone of formatting and sending at least one message by the second serverin accordance with the authentication initiative associated with thedetermined type of payment instrument, at least one of said formattingand said sending being prescribed differently by at least two of theauthentication initiatives.
 10. The method of claim 5, furthercomprising: determining which one of a plurality of differentauthentication initiatives is associated with the determined type ofpayment instrument used for the transaction; and selecting thedetermined authentication initiative for use in obtaining theauthentication determination.
 11. The method of claim 5, wherein theauthentication determination is obtained from a third server of a thirdparty, said third party maintaining an account for the account holder.12. The method of claim 5, wherein said obtaining comprises: making anenrollment determination, wherein said making an enrollmentdetermination includes determining whether or not the payment instrumentused for the transaction is enrolled to participate in theauthentication initiative associated with the type of payment instrumentused for the transaction.
 13. The method of claim 12, wherein makingsaid enrollment determination comprises: querying a directory serverthat identifies payment instruments enrolled to participate in aparticular authentication initiative.
 14. The method of claim 13,wherein at least two different directory servers are queried for atleast two different authentication initiatives.
 15. The method of claim12, wherein making said enrollment determination comprises: caching atthe second server a list of payment instruments enrolled to participatein authentication initiatives.
 16. A method of supporting account holderidentification in connection with a transaction conducted between ashopper and a merchant conducting an online transaction over a publicpacket-switched communication network, said shopper employing acomputing device supporting a browser thereon to access a first computersystem supporting a server of the merchant and thereby select one of aplurality of types of payment instruments accepted by the merchant forproviding payment in connection with said transaction, wherein at leasta first type of the plurality of payment instruments is associated witha first authentication initiative and a second type of the plurality ofpayment instruments is associated with a second authenticationinitiative, wherein the first and second authentication initiatives eachprescribe a set of procedures to be followed in order to authenticatethe shopper as an account holder, said method comprising: receiving afirst communication over the network at a second sever supported on asecond computer system; and determining from said first communicationthe type of payment instrument selected by the shopper; wherein: if thepayment instrument selected by the shopper is determined to be the firsttype, then obtaining an authentication determination according to theset of procedures prescribed by the first authentication initiative; andif the payment instrument selected by the shopper is determined to be ofthe second type, then obtaining an authentication determinationaccording to the set of procedures prescribed by the secondauthentication initiative.
 17. The method of claim 16, wherein the setof procedures prescribed by the first authentication initiative is notidentical to the set of procedures prescribed by the secondauthentication initiative.
 18. The method of claim 17, wherein the firsttype of payment instrument is a Visa card and the second type of paymentinstrument is a MasterCard.
 19. The method according to claim 18,wherein said determining is executed by said second server.
 20. Themethod according to claim 19, wherein each set of procedures prescribedby the first and second authentication initiatives defines at least oneof a way in which authentication determinations are formatted, alocation to which at least one message is routed in order to obtain anauthentication determination and a way in which at least one message ifformatted in order to obtain an authentication determination.